如果你曾經報名過 IT 邦幫忙鐵人賽，或者只是認真考慮過要不要挑戰連續 30 天的技術寫作，你大概對這個畫面不陌生。前幾天靈感充沛，一天寫一篇不成問題，甚至還能順手多琢磨幾張圖表。到了第十天左右，題目開始變得難找，你發現自己在半夜十一點盯著空白的編輯器，腦中反覆想著同一件事，今天到底要寫什麼、要寫到什麼深度、又要怎麼和昨天寫過的內容銜接起來，才不會讓讀者覺得這是兩個不同的人在寫同一個系列。

於是很多人動了同一個念頭，既然 ChatGPT 或 Claude 這麼會寫東西，乾脆把主題丟給它，一次生成一整篇 3000 字的文章，改一改標點符號就發布。這個念頭幾乎每個嘗試過長篇系列連載的工程師都動過，而多數人也很快就發現，這條路走不通。生成出來的文章乍看之下完成度很高，標題、小節、程式碼區塊一應俱全，但讀完前幾段就開始皺眉。哪裡怪，你可能一時說不上來，只覺得像是有人模仿你熟悉的技術寫作語氣，模仿得七八分像，卻在某些地方露出破綻。連續 35 天下來，如果每一天都靠這種方式生成，這些破綻只會越滾越大，最後整個系列讀起來像是好幾個風格迥異的作者輪流代筆。

問題出在哪裡，值得先說清楚，才知道這個系列到底要帶你去哪裡。真正的癥結既不是模型不夠聰明，也不是 Prompt 寫得不夠精準。把一整篇文章的規劃、查證、撰寫、審查全部塞進單一次推理裡，本身就是一種在架構上站不住腳的工作方式。這句話背後的具體機制，會在明天的 Day 01 完整拆解，這裡先不劇透結論，只需要記住一個方向：真正的解法，是把這整個創作過程拆解成多個角色，讓每個角色只負責一件事，再把這些角色串接成一套真正能撐過 35 天的系統，而不是指望找到某句更神奇的咒語讓模型一次到位。

這正是這個系列要帶你做的事。我們不會示範怎麼寫出更厲害的一鍵生成 Prompt，而是像軟體架構師規劃一套系統那樣，把「長篇技術系列寫作」這個任務拆解成規劃、撰寫、視覺、審查四種各司其職的 Agent，一步一步打造出來，最後把它們串成一條真正能協同運作的生產線。跟著這 35 天走完一輪，你會拿到的不只是一套工具，而是一套可以遷移到任何長篇寫作場景的系統化拆解與職責分工思維。

在往下看完整的 35 天地圖之前，先說明這篇 Day 00 的用途。它不會深入任何一天的技術細節，那是各天正文各自的任務。它的工作是把整個系列的骨架攤開來給你看一次，讓你隨時可以回來這裡確認自己正走在系列的哪個階段、前面完成了什麼、後面還有什麼在等著。

這個系列要示範的核心思維

在攤開 35 天地圖之前，先講清楚這個系列的立場。目標讀者是具備實際工程背景、用過 LLM 工具輔助寫作、也親身感受過「AI 寫的東西看起來像樣但讀起來怪怪的」的人。你不需要事先熟悉 Agent 框架或多 Agent 協同架構，這些名詞會在系列中逐步從零建立起來，唯一的預期門檻是你至少熟悉一種程式語言，以及 API 串接的基本概念。

系列的敘事節奏採取五段式弧線：先陳述問題，再搭建系統設計的骨架，接著逐一開發四類 Agent，然後把它們串接起來並讓系統能規模化運作，最後用一場實戰驗收，回頭檢驗開頭立下的承諾是否兌現。這條弧線背後有一條貫穿全系列的暗線值得先說在前面：第一階段會建立起一份「一鍵生成注定失敗」的病灶清單，接下來每打造完一個 Agent，都會回頭檢查它是否真的解決了清單上的某個具體病灶，直到最後一個階段用實際跑出來的產出數據，逐一驗收這份清單是否被徹底清空。這是一個首尾閉環的敘事設計，全系列 35 天都圍繞著這條線推進，而非把 35 天拆成互不相干的主題並列羅列。

35 天完整地圖

以下是系列全貌，依八個階段分組呈現。每個階段標題下方先說明這個階段要讓你建立起什麼樣的認知，再列出該階段每一天的標題與一句話定位。閱讀當下不需要理解每一天的細節，只需要對整體節奏有個印象，等你實際走到某一天，回來這裡對照一下自己的位置即可。

階段一：問題陳述，一鍵生成為什麼注定失敗，Day 01 - Day 03

這個階段只用三天，目標是讓你讀完之後，不需要依賴任何人背書，自己就講得出「為什麼一鍵生成無法用於長篇技術系列文章」的機制性理由，並且理解解法的方向是角色分工，但還不會接觸任何分工的具體細節。

• 《Day 01：為什麼傳統的「一鍵生成」寫不出好的長篇技術文章？》，拆解一鍵生成的機制性病灶，建立這個系列存在的必要性
• 《Day 02：產出優先思維，先定義規格再動筆》，從病灶推導出心法層級的解法方向，說明角色分工若沒有搭配正確的工作順序依然無效
• 《Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色》，首次揭曉完整的四類 Agent 分工架構與彼此的交接方式，只定義職責邊界，不展開實作

階段二：系統地基，規格化思維與知識庫建設，Day 04 - Day 07

在動手打造任何一個 Agent 之前，先把共享的基礎設施建好。這個階段要讓你理解，規劃代理人的工作依據是結構化規格與可檢索的知識庫，並具體認識規格書格式、全域一致性機制的作用，以及原始筆記如何被轉化成可供 Agent 檢索的知識庫單元。

• 《Day 04：規劃代理人的產出介面，認識 Section Spec》，定義規格書這個格式本身的結構與存在目的，作為規劃代理人與寫作代理人之間的正式交接介面
• 《Day 05：系列的單一事實來源，打造全域錨點檔案》，解釋多天協作為何需要一份記錄已定義名詞與架構決策的共享檔案
• 《Day 06：從筆記到知識庫，素材的收集與初步整理》，說明如何把既有筆記或素材整理成可供 Agent 使用的原始知識庫來源
• 《Day 07：知識庫的切分藝術，保留程式碼與上下文的完整性》，定義知識庫切分的方法，並討論切分過細導致語意斷裂的風險與應對原則

階段三：規劃代理人，從大綱到可執行規格，Day 08 - Day 13

系列中第一個被完整打造出來的 Agent，需要用六天把它做透。目標是讓你親手設計出一個規劃代理人，能依據主題、系列定位與天數，產出格式一致、且跨篇之間維持統一語氣與深度的結構化規格書。

• 《Day 08：規劃代理人的系統提示詞設計》，定義規劃代理人的角色設定與行為邊界，明確它只產出規格、不撰寫正文的原則
• 《Day 09：運用結構化推理模式產出大綱骨架》，教你如何讓規劃代理人先梳理邏輯再產出結構，避免大綱淪為主題關鍵字的隨意排列
• 《Day 10：定義文章的風格指南與目標受眾畫像》，建立可被所有 Agent 共用的風格與受眾定義，避免各天文章語氣各自漂移
• 《Day 11：避免內容漂移，跨篇一致性的機制設計》，針對前面階段定義的內容漂移問題，設計規劃階段就能預防的具體機制
• 《Day 12：規格書的自我檢查，規劃代理人如何驗證自己的產出》，討論規劃代理人產出規格後的自我校驗步驟，避免規格本身帶有邏輯漏洞
• 《Day 13：實戰，讓規劃代理人產出一套完整的系列大綱》，完整跑一次規劃代理人的實際產出流程，作為本階段的收尾驗收

階段四：寫作代理人，查證與撰寫的協同，Day 14 - Day 20

系列篇幅最長的階段，共七天，因為這裡直接對應第一階段揭露的問題中技術含量最高、最需要具體案例支撐的部分。目標是讓你打造出一個依據規格書進行撰寫、且具備即時查證能力的寫作代理人，讓產出內容在程式碼正確性與跨篇狀態記憶上都優於一鍵生成。

• 《Day 14：寫作代理人的架構設計，從規格到草稿]]，定義寫作代理人如何讀取規格書並轉化為實際段落草稿的工作流程
• 《Day 15：結合即時查證，讓寫作代理人自己查資料》，引入讓寫作代理人交錯推理與外部查詢動作的工作模式
• 《Day 16：程式碼生成的正確性保證機制》，設計確保程式碼範例可執行且版本正確的具體機制
• 《Day 17：狀態管理，讓寫作代理人記得前幾天寫過什麼》，解決跨篇重複與知識預設不一致的問題
• 《Day 18：處理複雜內容，長篇論證與公式推導的撰寫策略》，討論篇幅較長或邏輯層次較深的段落，寫作代理人如何維持論證的緊密度不鬆散
• 《Day 19：事實查證與撰寫的分工邊界》，釐清寫作代理人的查證職責與審查代理人的查核職責如何劃分，避免兩者工作重疊
• 《Day 20：實戰，寫作代理人依規格產出完整初稿》，完整跑一次寫作代理人的實際產出流程，並回顧問題在寫作階段被解決的程度

階段五：視覺代理人，讓文章圖文並茂，Day 21 - Day 25

五天，目標是讓你理解為什麼技術文章需要視覺輔助，並打造一個能依據文章內容自動產生架構圖、資料圖表與封面配圖的視覺代理人，最終與寫作代理人協同產出圖文整合的草稿。

• 《Day 21：為什麼技術文章需要圖表，視覺代理人的定位》，說明視覺輔助對技術文章理解效率的作用，並定義視覺代理人的職責邊界
• 《Day 22：自動生成架構圖，讓代理人依內文繪製流程圖》，教你如何讓視覺代理人依據文章內容產出流程性質的圖表
• 《Day 23：資料視覺化，讓代理人讀取數據並生成圖表》，教你如何讓視覺代理人依據數據資料產出統計或比較性質的圖表
• 《Day 24：封面與插圖生成，用生成式圖像工具自動配圖》，討論如何讓視覺代理人自動產出文章封面與插圖，並兼顧風格一致性
• 《Day 25：實戰，寫作與視覺雙代理人協同產出圖文草稿》，完整跑一次寫作代理人與視覺代理人協同產出的流程，驗證多 Agent 架構的可擴充性

階段六：審查代理人與人機協同守門，Day 26 - Day 30

五天，目標是讓你打造一個扮演最嚴苛讀者角色的審查代理人，具備事實查核與去 AI 腔調的能力，並設計出明確的 Human-in-the-loop 節點，確保系統在關鍵決策點保留人類判斷。

• 《Day 26：審查代理人的設計，扮演最嚴苛的讀者》，定義審查代理人的角色設定與評判標準的建立方式
• 《Day 27：事實查核機制，攔截技術文章中的幻覺》，設計成文後攔截錯誤或過時資訊的最後一道查核防線
• 《Day 28：Human-in-the-loop 設計，人類該在哪裡介入》，定義系統中哪些節點必須保留人類判斷
• 《Day 29：可讀性與去 AI 腔調的審查標準》，定義審查代理人如何辨識並修正 AI 腔調句型與可讀性問題
• 《Day 30：格式與排版的自動校對》，討論 Markdown 語法、排版一致性等機械性檢查如何交由審查代理人自動完成

階段七：工作流編排與多平台發佈，Day 31 - Day 33

刻意壓縮為三天，因為四類 Agent 各自的職責已經在前面講完，這三天的任務是把已經存在的四個獨立單元組裝成系統。目標是把四類 Agent 串接成一條具備錯誤處理能力的自動化工作流，並讓最終產出能適應不同平台的格式需求並完成發佈。

• 《Day 31：把四個代理人串成一條生產線》，說明如何設計工作流編排邏輯，讓四類 Agent 依序或並行協作而不互相干擾
• 《Day 32：錯誤處理與重試機制設計》，討論當任一環節的 Agent 呼叫失敗或產出不符規格時，系統如何偵測並重試或中止
• 《Day 33：多平台格式轉換與自動發佈》，說明如何將統一格式的成品轉換為不同平台各自需要的格式並完成發佈

階段八：實戰驗收與總結，Day 34 - Day 35

系列的收尾，兩天。目標是讓你看到整條生產線被實際跑過一次的具體結果，並且透過量化與定性反思，理解人機協同寫作系統的真實效益與限制。

• 《Day 34：實戰演練，跑完一次完整生產線並量化評估》，實際執行整條生產線一次，並用數據回頭驗證第一階段提出的問題是否真的被解決
• 《Day 35：完賽總結，人機協同寫作系統的定位與限制》，呼應系列開場的問題，總結系列成果，並誠實檢討系統的限制與不適用場景

小結：這套地圖存在的意義

35 天的天數配置刻意不均分，這是一套有意識設計的系統開發順序。規劃代理人與寫作代理人這兩個核心階段確實需要比其他階段更多篇幅。系統地基階段之所以獨立出來，理由在於知識庫與規格書格式本來就是後續所有 Agent 共同依賴的基礎，應該在動手打造任何一個 Agent 之前就先建好。你在後面某一天如果覺得進度卡住，回來對照這份地圖，通常能立刻看出自己是在哪個階段的哪個環節卡關，不必漫無目的地往前翻。

這份地圖上的每一格，都是為了兌現一個承諾：把「連續 35 天穩定產出高質量技術文章」這件事，從一場靠意志力支撐的馬拉松，變成一套有架構可依循的系統工程。這件事光看地圖還無法被說服，需要跟著往下走，一步一步驗證每個階段是否真的兌現了它的承諾。

明天我們將正式進入 《Day 01：為什麼傳統的「一鍵生成」寫不出好的長篇技術文章？》，把今天先按下不表的機制性理由，一一攤開來看清楚。